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NETWORK APPLICATION PROGRAM INTERFACE 
FACILITATING COMMUNICATION 
IN A DISTRIBUTED NETWORK ENVIRONMENT 



RELATED APPLICATION 

This application claims the benefit under 35 U.S.C. § 119(e) of U.S. 
Provisional Application Serial No. 60/225,366, filed August 14, 2000 for "System and 
Method for Describing and Executing an Application Program Interface Over the 
5 Internet." 



TECHNICAL FIELD OF THE INVENTION 

The invention relates in general to communications, and more particularly to a 
network application program interface (API) that facilitates communication within a 
10 distributed network environment. 
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BACKGROUND OF THE INVENTION 

As the commercial significance of the Internet has increased, business-to- 
consumer ("B2C"), business-to business ("B2B"), and other electronic marketplaces 
have become increasingly prevalent. Each marketplace typically uses a different set 
5 of software applications, with possibly different underlying technologies, to provide 

the communication capabilities that potential users of the marketplace expect. For 
example, a marketplace hub server at one enterprise may wish to communicate with 
another marketplace hub server at a different enterprise. Additionally, other types of 
servers may want to participate in marketplace transactions with a marketplace hub 
10 server. Such servers may be associated with legacy systems at remote enterprises, 

which may or may not be "Internet aware." Lack of a mechanism providing effective 
integration of these disparate systems can unduly restrain or even prohibit effective 
marketplace participation by such systems and associated users. 
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SUMMARY OF THE INVENTION 

According to the present invention, one or more problems and disadvantages 
associated with communication in distributed network environments may be reduced 
or eliminated. 

5 In one embodiment of the present invention, a computer-implemented system 

includes a request broker that receives a network API request component from a 
client, the network API request component including a description of a system API 
method to be called and one or more parameters to be used in executing the system 
API method. The parameters have one of multiple acceptable native formats. The 

10 request broker determines the native format of the parameters and communicates the 

parameters in the native format to a selected one of a collection of translators for 
translation of the parameters from the native format to an internal format, each 
translator being associated with a different native format. The request broker 
communicates the parameters in the internal format to an application server system to 

15 enable execution of the system API method according to the parameters and receives 

a return value from the application server system in the internal format reflecting the 
execution of the system API method according to the parameters. The request broker 
communicates the return value in the internal format to the selected translator for 
translation of the return value from the internal format to the native format, generates 

20 a network API reply component that comprises the description of the system API 

method that was called and the return value in the native format, and communicates 
the network API reply component to the client. 

Certain embodiments of the present invention may provide one or more 
technical advantages over prior communication techniques. Certain embodiments of 

25 the invention may provide a mechanism for describing and executing an application 

program interface (API) in a distributed network environment such as the Internet, 
including providing the ability to receive and return values from API calls and to 
return exception and deprecation notices when appropriate. Certain embodiments of 
the invention may allow disparate remote clients to interact with a hub system using 

30 disparate corresponding data representations, such as Extensible Markup Language 

(XML), Electronic Data Interchange (EDI), relational, serialized object (e.g., JAVA), 
or relational formats, using a generic cross-firewall API mechanism. This may allow 
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integration with these disparate remote clients in a generic manner, allowing such 
disparate remote clients to directly interact with the hub system without requiring 
implementation of interaction or communication protocols tailored for each disparate 
remote client. This may further allow appropriate planning or other collaborative 
engine capabilities to be exposed in a standard fashion to integrators associated with 
such disparate remote clients. Certain embodiments of the invention may provide 
execution of "document-based" or other asynchronous API calls as well as "function 
based" or other synchronous API calls, allowing bulk or transactional interactions to 
be dealt with efficiently, and may also support a "versioned" API concept. 

Systems and methods incorporating one or more of these or other advantages 
may be well suited for modern commercial transaction environments such as those 
associated with electronic marketplaces. Other technical advantages may be readily 
apparent to those skilled in the art from the figures, descriptions and claims included 
herein. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIGURE 1 illustrates an example hub system in communication with one or 
more remote systems in a distributed network environment using a network API; 

FIGURE 2 illustrates an example hub system in further detail; 
5 FIGURE 3 illustrates an example request-response protocol associated with a 

network API; 

FIGURE 4 illustrates an example network API message format; 
FIGURE 5 illustrates an example network API request component; 
FIGURE 6 illustrates an example network API reply component; and 
10 FIGURE 7 illustrates an example network API exception-report component. 
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DETAILED DESCRIPTION OF THE INVENTION 

FIGURE 1 illustrates an example hub system 12 in communication with one 
or more remote systems 14 in a distributed network environment. Hub system 12 
includes a hub server complex 16 that communicates with one or more clients 18 
using API- based communications over links 20. Links 20 may include one or more 
local area networks (LANs), metropolitan area networks (MANs), wide area networks 
(WANs), portions of a global computer network such as the Internet, or any other 
wireline, optical, wireless, or other links. In one embodiment, the hub system 12 is 
associated with a B2C, B2B, or other electronic marketplace and the client systems 14 
may be associated with one or more remote electronic marketplaces, one or more 
remote servers, one or more remote applications (such as legacy or other enterprise 
systems), or any other remote entities that access the resources of or otherwise 
communicate with hub system 12. Such remote entities may be referred to as clients 
18 of hub server 12. Hub system 12 and client systems 14 may include firewalls 22 
that protect the resources of hub server complex 16 and clients 18, respectively. 

In general, the network API associated with hub system 12 operates to expose 
a hub API associated with hub server complex 16 to clients 18, and to provide clients 
18 with access to associated publish and subscribe event capabilities, via the Internet 
or other links 20. The network API may also provide a document exchange capability 
that allows for bulk transaction interaction between clients 18 and hub server complex 
16. In one embodiment, all clients 18 behave similarly from the perspective of hub 
server complex 16. Hub system 12 includes one or more API adapters 24 suitable for 
translating the one or more API formats used by clients 18 to a format appropriate for 
the hub API, each such format preferably having a corresponding API adapter 24. As 
described more fully below, each API adapter 24 is able to build hub API commands 
from network API requests and build network API responses from the corresponding 
hub API replies. For certain embodiment, even asynchronous hub API requests may 
require minimal response to client 18 indicating that the request was received. 

The components of hub system 12 may operate on one or more computers at 
one or more locations. One or more computers associated with hub system 12 may 
share processing, data storage, or other suitable resources. For example, hub server 
complex 16 may include one or more server computers that support one or more 



ATTORNEY'S DOCKET 
020431.0729 



PATENT APPLICATION 



applications, modules, engines, programs, or any other software components suitable 
to provide the features and operation described herein. As a more particular example 
where the hub server complex 16 is associated with an electronic marketplace, the 
applications supported by hub server complex 16 may include service applications, 
5 order capture applications, and order management applications. Service applications 

may include a catalog application, a pricing application, a contract application, a user 
profile application, or any other appropriate application relating to the services that 
hub system 12 provides to clients 18 acting as buyers. Order capture applications 
may include an ordering application, an auction application, a requisition application, 

10 a procurement application, or any other suitable application relating to handling of 

orders received from these clients 18. Order management applications may include 
an order administration application, a returns management application, a settlement 
application, or any other suitable application relating to the management of orders. 
However, as described above, the present invention may be incorporated into any 

15 suitable hub system 12 according to particular needs. 

One or more clients 18 may not be "Internet aware" or might otherwise be 
incapable of participating in marketplace transactions with hub system 12, absent 
particular accommodations. In one embodiment, the network API associated with 
hub system 12 provides one or more of the following features, without limitation: (1) 

20 the ability to execute "document-based" or other asynchronous API calls as well as 

"function based" or other synchronous API calls; (2) the ability to receive and return 
values for API calls, as well as exception and deprecation notices; (3) support for 
multiple formats for describing API calls, such as XML, EDI, relational, serialized 
object (e.g., JAVA), or other appropriate formats; (4) support for Hypertext Transport 

25 Protocol (HTTP) tunneling for traversing firewalls 22; (5) guaranteed execution of 

API calls (i.e. guaranteed message delivery); (6) versioning support; and (7) secure 
API calls. Any of these or other features may contribute to the ability of hub system 
12 to integrate multiple disparate clients 18 in a generic manner and directly interact 
with such clients 18 without implementing interaction or communication protocols 

30 tailored specially for each client 18. For example, the network API of hub system 12 
may expose planning and collaborative engine capabilities of hub system 12 to client 



ATTORNEY'S DOCKET 
020431.0729 



PATENT APPLICATION 



8 

integrators in a standard fashion. The network API may also allow bulk transaction 
interaction to be dealt with in a more efficient manner. 

In one embodiment, communications may be initiated from client systems 14 
to hub system 12, which may provide a level of security to client systems 14 because 
no inbound connections will be required and no ports in associated firewalls 22 will 
need to be opened for communication with hub system 12. Instead, hub system 12 
maintains one or more open ports in its firewall 22 for communication with client 
systems 14. Where client system 14 is a remote hub system 12, both hub systems 12 
will have open ports to service normal requests, such that the same port may be used 
for communication between these hub systems 12. Secure HTTP (HTTPS) may be 
used as the transport layer for exchanging information between hub system 12 and 
client systems 14, providing the benefit of a widely accepted mechanism, allowing 
"tunneling" through various types of security firewall arrangements, and providing 
other features described herein. As described below, hub server complex 16 of hub 
system 12 may include a Secure Socket Layer (SSL) enabled HTTPS web server to 
provide communication with client systems 14. 

FIGURE 2 illustrates an example hub system 12 in which hub server complex 
16 includes one or more HTTPS or other suitable web servers 30, one or more hub 
application servers 32, and one or more databases 34. Inbound and outbound event 
queues 36a and 36b, respectively, contain events (or transition notices reflecting the 
events) to be communicated from web server 30 to hub application server 32 or from 
hub application server 32 to web server 30, respectively. Hub application server 32 
supports one or more applications 38 that provide functionality desired by the clients 
18 accessing hub system 12. Hub application server 32 may support, for example, a 
collaborative planning application 38 that accesses data stored in database 34, which 
may be based on demand forecast data, available-to-promise (ATP) data, inventory 
data, or other suitable data received from the enterprise applications of clients 18, to 
provide collaborative planning for at least a portion of a supply chain that includes 
these clients 18. However, the present invention contemplates hub system 12 with 
any appropriate hub application server 32, associated applications 38, and associated 
database 34 in accordance with particular needs. 
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In one embodiment, the functionality of applications 38 that execute in hub 
application server 32 may be represented as business object each having a particular 
state at any given time. When an action is performed on a business object, it changes 
state. This transition can be considered an event that is of interest to an appropriate 
event handler associated with event queues 36. In general, applications 38 may post 
transition notices to event queue 36 and event handlers may access event queue 36 to 
consume associated events as appropriate. In a particular embodiment, these event 
handlers may be of three types: (1) transient, (2) persistent, and (3) guaranteed. The 
transient type is for events that if lost are not critical, such as informational events 
which are not persisted and therefore could be lost if system shutdown occurs. The 
transient event mechanism is a fast memory based approach. Persistent events are 
stored in database 34 for removal by a persistent event handler upon consumption. 
The persistent event handler takes full responsibility for properly delivering the event 
to its consumer. The guaranteed event mechanism implements guaranteed delivery 
semantics, by which a guaranteed handler will converse with the event framework to 
achieve guaranteed delivery of the event to its consumer. Although particular event 
handling strategies are described, the present invention contemplates any appropriate 
technique for communicating events (or transition notices reflecting events) between 
hub application server 32 and consumers of the events. 

Occasionally, clients 1 8 may wish to receive notification of any interesting 
occurrences by way of an active push from hub system 12 to their client systems 14. 
Clients 18 may be running diverse event consumption technologies (e.g., HTTP, e- 
mail, etc.). In one embodiment, pre-built event consumers may be provided when a 
proprietor of hub system 12 provides certain spoke technology or hub technology on 
the client side. For any clients 18 that have specific implementations, specific push 
mechanisms may need to be built. As noted above, for easier firewall transversal and 
easier deployment, the push mechanism is preferably used only if client 18 objects to 
using a polling mechanism for event notification. A pattern may be defined to allow 
development of appropriate push client mechanisms. 

FIGURE 3 illustrates an example request-response protocol associated with 
the network API supported by hub system 12. In one embodiment, a servlet running 
in web server 30 acts as a request broker 50 to provide translation between network 
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API (NAPI) and hub API (HAPI) commands. Request broker 50 receives a NAPI 
request contained within an HTTP request, interprets the format of the wrapper that 
contains the NAPI request (e.g., Multi-purpose Internet Mail Extensions (MIME)), 
determines the format in which the one or more parameters of the NAPI request are 
5 represented (e.g., XML, EDI, serialized object (JAVA), relational, etc.), selects an 

appropriate adapter 24 for the NAPI request based on the format of the parameters, 
and passes the parameters to the selected adapter 24 in their native format using an 
adapter interface 52. In one embodiment, as is shown, passing the parameters to the 
selected adapter 24 involves request broker 50 calling a method on adapter interface 

10 52 to get adapter 24 and then calling a method on adapter interface 52 to pass the 

parameters to adapter 24. Adapter 24 converts the formatted parameters to JAVA 
classes or any other representation suitable for processing at hub application server 
32, according to the implementation. 

Request broker 50 may select an appropriate application server adapter 54 for 

15 hub application server 32, according to the application 38 to be used to handle the 

NAPI request, and passes the parameters (now converted to JAVA classes according 
to the particular implementation) to selected application server adapter 54. In one 
embodiment, as is shown, passing the parameters to the selected application server 
adapter 54 involves request broker 50 calling a method on request broker 50 to get a 

20 Uniform Resource Locator (URL) or other address of application server adapter 54 

and then calling a method on application server adapter 54 to pass the parameters to 
application server adapter 54. Request broker 50 obtains an appropriate return value 
in response to calling the method in application server adapter 54, the return value 
reflecting processing of the parameters by an appropriate application 38 running on 

25 hub application server 32. Request broker 50 gives the return value (represented in 

JAVA classes according to the particular implementation) to the selected adapter 24, 
which then returns a return value in the same format as the original NAPI request. In 
one embodiment, as is shown, giving the return value adapter 24 involves calling a 
method on adapter 24. Request broker 50 generates a NAPI response containing the 

30 return value, wraps the NAPI response and associated return value in an appropriate 
wrapper (e.g., a MIME wrapper), and communicates an HTTP response containing 
the wrapped NAPI response and associated return value to client 18. For document- 
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based or batch-based modes, the same mechanism may be followed, except that the 
NAPI request is typically a "saveDocumentAndProcess" type request. This is the 
mechanism that is preferably used for upload/download capabilities that hub system 
12 may use. 

Because the mechanism described above waits until a return value is received 
from the final recipient of the NAPI request (i.e. selected application server adapter 
54) before communicating any response to the originator of the NAPI request (i.e. 
client 18), a level of guaranteed messaging may be achieved. In one embodiment, 
client 18 will know upon receiving the NAPI response that the final recipient has in 
fact received the API call. However, the possibility exists that if the connection 
between client 18 and web server 30 is dropped after the method is executed, but 
before an associated reply is received by client 18, duplicate delivery of the API call 
may occur. Due to the behavior of request broker 50, guaranteed message delivery 
can be achieved such that request broker 50 recognizes any duplicate delivery and 
handle it accordingly. If client 18 does not receive a NAPI response to its request, 
client 18 may assume that request broker 50 has not received the request and that 
client 18 may resubmit the request until an appropriate response is received. If there 
is a failure in submitting the request, either client 18 will receive an error notification 
or its connection with the web server 30 will be dropped. This provides a proper 
indication to client 18 that its request was not delivered and should be re-attempted. 
If the transmission of the response fails, client 1 8 will not receive the response or its 
connection will be dropped, and client 18 will know that another attempt to deliver 
the request should occur. 

As the above description makes clear, communication between request broker 
50 and client 18 involves a request-response protocol. Method execution in other 
environments would typically involve a client 18 calling a method and expecting a 
return type generated by the request. The same scenario exists in the environment of 
system 10, except that the method is instead executed remotely from client 18 (e.g., 
by application server adapter 54 of hub system 12) with link 20 (e.g., the Internet) 
being the mechanism to communicate information between the caller of the method 
(client 18) and the executor of the method (application server adapter 54). 
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When the duration of a method invocation (i.e. message passing) is relatively 
large (e.g., large file upload, long computational method, etc.), an asynchronous (i.e. 
document-based) invocation semantic is preferably used to avoid tying up network 
connections, database connections, and other resources for long periods. This also 
5 helps avoid clients 18 having to "block" or otherwise suspend communications for a 

long period and potentially timing out. When the duration of a method invocation is 
relatively small, either an asynchronous or synchronous (function-based) invocation 
semantic may be employed. In general however, a synchronous mode is preferred 
over an asynchronous mode because coding of components of hub system 12 and 

10 client systems 14 may be simpler in the synchronous case. 

In one embodiment, request broker 50 may maintain an access control list to 
prevent unauthorized execution of methods. Client 18 may be required to connect to 
web server 30 with a username and a password, which controls general access to the 
resources of hub system 12. In addition, the access control list may specify all the 

15 methods that may be executed within hub system 12. Where access to at least some 

methods is restricted to certain clients 18, the access control list may further specify 
which methods are accessible to which clients 18. If access to a particular method, 
generally or by a particular client 18, is not specified in the access control list, the 
method will not be executed. 

20 FIGURE 4 illustrates an example network API (NAPI) message format 70, 

which in one embodiment includes a MIME envelope 72 having a content type 74 set 
to multipart/mixed and including a boundary definition, and a NAPI component 76. 
NAPI component 76 may be request component 76a (as illustrated in FIGURE 5), a 
response component 76b (as illustrated in FIGURE 6), an exception component 76c 

25 (as illustrated in FIGURE 7), or any other suitable component 74. 

FIGURE 5 illustrates an example NAPI request component 76a received at 
hub system 12 from a client 18. In one embodiment, request component 76a may 
include a NAPI request content type 78 including a boundary definition, a content 
disposition 80 including a NAPI version, a hub API (HAPI) descriptor 82 including a 

30 description of the HAPI method to call, and one or more NAPI parameters 84 used to 
execute the called method. The format for parameters 84 defines which adapter 24 
will be chosen to interpret the request and to build the corresponding reply for the 
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session. As described above, for example, the format may be XML, EDI, serialized 
object (e.g., JAVA), relational, or any other suitable format according to particular 
needs. Parameters 84 are preferably (and in one embodiment must be) given in the 
order the parameters 84 appear in the method call. If no parameters 84 exist in the 
5 method signature, then request component 76a will not include any parameters 84 in 

addition to descriptor 82. 

An example request component 76a may be defined as follows: 



Content-Type: multipart/mixed; boundary="NAPI BOUNDARY" 

10 

~NAPI_B OUND ARY 

Content-Type: application/napi-request; boundary=" COMPONENT_BOUND ARY" 
Content-Disposition: inline; version=1.0 

15 — COMPONENTBOUNDARY 

Content-Type : application/napi-method 
Content-Disposition: inline 

AccessorURL=urlName 
20 MethodName=methodName 

-COMPONENTBOUNDARY 
Content-Type: application/napi-parameter 
Content- Transfer-Encoding: base64 
25 Content-Disposition: inline; format_type="JAVA" 

0M8R4KGxGuEAAAAAAAAAAAAAAAAAA 
AAANwAAAAEAAAD+////AAAAADQAAAD 

IlilllllllllllllllllllllllHllllllllMlllHlllilllllllHIIIIIIIIIIIIIII 
30 lll!!llll!lllllll!lll!llll!ll!!ll/!III!lll!llll!II/!lll!lll!li!llll/!UI 
ilillllllllllilllllilllllllllllllllUllllllllllIllllllllllllilllllllllll 

-COMPONENTBOUNDARY 
Content-Type : application/ napi-parameter 
3 5 Content-Transfer-Encoding: base64 

Content-Disposition: inline; format_type="JAVA" 

0M8R4KGxGuEAAAAAAAAAAAAAAAAAA 
AAANwAAAAEAAAD+////AAAAADQAAAD 

40 lllllllllllllllllllllllillllllllllllllllllllllllllllllllllllllllllllllll 

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIHII/HIIIIIHIIIIIIIIIIIIIIIIIIIHIIII 

llltllllllllllllllllltlillllllllllllllMIIIHIIllllllllllllHIIUIUIII 

IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIHIIIIIIII 

lll!lli/IIIIIIll!!ll/llil!lllllilllllllll/III!!lllllIlllli!!ll/!IIIIIHI 
45 -COMPONENTBOUNDARY- 

— NAPIBOUNDARY — 
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FIGURE 6 illustrates an example NAPI reply component 76b communicated 
from hub system 12 to client 18. In one embodiment, reply component 76b may 
include a NAPI reply content type 78 that includes a boundary definition, a content 
disposition 80 that includes a NAPI version, a HAPI descriptor 82 that includes a 
description of the HAPI method called, and a NAPI return value 86 from executing 
the method. The format field of the return value 86 will preferably describe how to 
interpret the return value 86, corresponding to the adapter 24 that was used. Where 
appropriate, reply component 76b may include a deprecation notice 88 that indicates 
to the calling client 18 that the called method should not be further used. 

An example reply component 76b may be defined as follows: 

Content-Type: multipart/mixed; boundary="NAPI_BOUNDARY" 
--NAPIBOUNDARY 

Content-Type: application/napi-reply; boundary="COMPONENT_BOUNDARY" 
Content-Disposition: inline; version=1.0 

AccessorURL=urlName 
MethodName=methodName 

--COMPQNENTBOUNDARY 
Content-Type: application/napi-return-vahie; 
Content-Transfer-Encoding: base64 
Content-Disposition: inline; format="JAVA" 

0M8R4KGxGuEAAAAAAAAAAAAAAAAAA 
AAANwAAAAEAAAD+////AAAAADQAAAD 

IllllllllltlllllllllllllllllllllllllllllllllllilllllllllllllllllllUIIII 

JIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIHIIIHWIIIIIIIIIIIIIIIHIIIHII/III 

IIIIIIIIIIIIIIUlllllllIIIIIIIIHIIIIIIIIIIIIIIIIIIIIIIIIIllllllllUllll 

IIIIIIIIIilllllllHllllllllllllllllllllllllHIIIIIHIIIIIllHIIIIIIIIII! 

l!llll!IIII!IIUillllllllll!lll!lllll!ltllltllllll!lllll!!!l!l!!Ullllll 

~COMPONENT_BOUNDARY~ 

-NAPI_B OUNDARY-- 

An example reply component 76a with an attached deprecation notice 88 may 
be defined as follows: 

Content-Type: multipart/mixed; boundary="NAPI_BOUNDARY" 
~NAPI_B OUNDARY 

Content- Type: application/napi-reply; boimdaiy="COMPONENT_BOUNDARY" 
Content-Disposition: inline; version=1.0 

AccessorURL=urlName 
MethodName=methodName 
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--COMPONENTBOUNDARY 
Content-Type : application/napi-return-value; 
Content-Transfer-Encoding: base64 
Content-Disposition: inline; format="JAVA" 

5 

0M8R4KGxGuEAAAAAAAAAAAAAAAAAA 
AAANwAAAAEAAAD+////AAAAADQAAAD 

IlllllllllllllllilllllllllllllllllllllllllllllllillllllllllllHIIIIIIIII 
10 llllllllllllllllllilll/lllllllHlllllll/IIIIIIllllllillllllHIIIIMIIII 
l!llllll//IIJ/tl!/IIIIIIII/lll/IIIIIII!/!ll/III/!ll/iIIII!I//IIJ/III/!ll 
IlllllllllllllillllllllllilllllllllllllllUlilllllllillllllilllllllllllj 
— COMPONENT_BOUNDARY 
Content-Type : application/napi-deprecation-notice; 

15 

This method has been deprecated. 
--COMPONENTJBOUNDARY-- 
— NAPI_BOUNDARY— 

20 

FIGURE 7 illustrates an example NAPI exception component 76c that might 
be communicated from hub system 12 to client 18. In one embodiment, exception 
component 76c may include a NAPI exception-report content type 78 that includes a 
boundary definition, a content disposition 80 that includes a NAPI version, a HAPI 

25 descriptor 82 that includes a description of the HAPI method called, and a NAPI 

exception descriptor 90 that includes description of the exception that occurred. As 
for reply component 76b described above, where appropriate, exception component 
76c may include a deprecation notice 88 indicating to the calling client 18 that the 
called method should not be further used. 

30 An example exception component 76c may be defined as follows: 



Content-Type: multipart/mixed; boundary="NAPI_BOUNDARY" 
— NAPIB OUND ARY 

35 Content-Type:application/napi-exception-Teport;boundary=''COMPONENT_BOUNDARY M 
Content-Disposition: inline; version=1.0 

AccessorURL=urlName 
MethodName=methodName 

40 

— COMPONENTBOUNDARY 
Content-Type: text/plain; 



45 



Application threw exception: "Reason for exception being thrown" 

~COMPONENT_BOUNDARY- 

— NAPIBOUNDARY-- 
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An example exception component 76c with an attached deprecation notice 88 
may be defined as follows: 



5 Content-Type: multipart/mixed; boundary="NAPI_BOUNDARY" 

— NAPIBOUNDARY 

Conten^Type:application/napi-exception-report;boundary= , 'COMPONENT_BOIINDARY , ' 
Content-Disposition: inline; version=1.0 

10 

AccessorURL=urlName 
MethodName=methodName 

--COMPONENTBOUNDARY 
15 Content-Type: text/plain; 

Application threw exception: "Reason for exception being thrown" 

--COMPONENT JBOUNDARY 
20 Content-Type: application/napi-deprecation-notice; 

This method has been deprecated. 
-COMPONENTBOUNDARY- 
--NAPIBOUNDARY — 

25 

Although the present invention has been described with several embodiments, 
a plethora of changes, substitutions, variations, alterations, and modifications may be 
suggested to one skilled in the art, and it is intended that the invention encompass all 
30 such changes, substitutions, variations, alterations, and modifications as fall within the 

spirit and scope of the appended claims. 



